OPC Data Client manages connections (COM OPC Server object instances in OPC Classic, HTTP in OPC XML-DA, or UA sessions in OPC UA) from the client (your application) to the server automatically, That is, you do not have to do anything explicitly to open the connection, or to close it. OPC Data Client opens the connection when it is needed, and it closes it when it is no longer in use for some time. It also keeps the connection open when it is needed to perform some long-running function (such as when you have subscriptions). OPC Data Client also attempt to re-establish the connection if it gets broken by circumstances external to your application, such as network disruptions, or problems on the server side. All of this happens automatically and "behind the scenes".
In some cases, however, you may want a better control of the OPC client-server connections.
You may want, for example, to assure that the connection stays open, in order to improve performance (because opening and closing the connection takes some time). Or, some (relatively rare) concepts work with data that are only valid for a lifetime of a particular connection, and therefore you need to assure that the connection is open during certain period. For example, in OPC UA, the file handle is "tied" to a UA session that created it.
In OPC UA, you can control the client-server connections using the IEasyUAClientConnectionControl service that you obtain from the EasyUAClient component.
The LockConnection Method on the IEasyUAClientConnectionControl Interface locks a connection to the specified endpoint descriptor. This means that the component will attempt to open the connection and keep it open, until it is explicitly unlocked. While the connection is locked, operations with the same endpoint descriptor will use the connection that is locked and already open. The method returns a lock handle (an integer) that can be later used to unlock the connection. It is not an error to lock the connection with the same endpoint descriptor multiple times; each of these will return its own, different lock handle. The component keeps an internal count of locks with the same endpoint descriptor, and the connection is effectively unlocked only if there are no existing locks with that endpoint descriptor. You eventually need to unlock each of the obtained lock handles (in any order).
The UnlockConnection Method on the IEasyUAClientConnectionControl Interface unlocks a connection that has previously been locked. You need to pass it a lock handle obtained previously from the LockConnection Method. If there are no other locks with the same endpoint descriptor, the connection will no longer be locked, and the component can close it (if not in conflict with other rules - such as that the connection is kept open for any existing subscriptions). The lock handle you pass to the UnlockConnection Method becomes invalid and you can no longer use it.
The methods that lock or unlock the connection work asynchronously, i.e. opening or closing the connection may happen after the control has returned from the method back to your code.
The methods do not throw exceptions or return any error indication in case of failure related to locking and unlocking. If you need the information related to such errors situations, you can use the OPC Data Client Operation Monitoring Services.
In .NET, it is possible to further simplify the connection locking and unlocking code, by using an extension DisposableLockConnection Method. This method locks a connection in the same way as the LockConnection Method does, but instead of returning an integer lock handle that you will later use with the UnlockConnection Method, it returns an IDisposable object, implemented in such a way that disposing of it (using its Dispose Method) unlocks the connection. The underlying functionality is identical, but the disposable lock object plays nicely with language constructs available in most .NET languages, such as the using statement in C# or the Using Statement in VB.NET. Not only allow these language construct for shorter and clearer code, but they also guarantee that the object will be disposed (and therefore the connection unlocked) not only when the control flows normally through the body of the statement block, but also in cases when an exception is thrown and the control leaves the block via the exception. This reduces or eliminates the potential for nasty coding errors which can otherwise leave the connections locked when they should not be.
A corresponding service is not currently available for OPC Classic.